The approach described herein is generally directed to version management of the contents of computer files. An electronic entity may comprise an aggregation of the content of files stored and maintained separately from one another, and some of these files may be mutually dependent. An example of such an entity may be source code for a software application, where the source code is distributed across multiple source files. Another example may be a master schedule distributed across files that contain task lists and due dates for multiple teams or individuals. Another example may be a book where the chapters are maintained separately in different files, but the chapters contain cross-references to locations within other chapters. Changes to an entity may require modifications to multiple files, and the entity may not be in a consistent state until all of the modifications are completed.
A common problem when developing or maintaining an electronic entity comprised of content stored in independently updated components, such as files, is obtaining a consistent snapshot of the entity at an historical point in time. Even though each component may progress through a sequence of states, it may be valuable to be able to visualize the overall state of the entity across all components. For example, a software development project may comprise multiple source files that are compiled and linked together to form an executable file. One source file may define a function that is called by code residing in a different source file. If the one source file is changed to redefine the function, code in the different source file that calls the function may need a corresponding change. Thus, the file containing the calling code has a dependency on the file defining the function, even though these files may be updated independently.
Many component files may have been opened, edited, and closed over time. Frequently, users have worked on files and decided that they want to revert their changes to an earlier state—e.g., they are unhappy with the last few hours of work and want to start over from an earlier point. However, reverting a set of related files to an historical time point may be time-consuming and error-prone. Previous attempts to provide tool support for this process have only allowed viewing changes for one file at a time and reverting changes one file at a time. Also, there has been no easy way to see a timeline showing changes in separate but related files.
Source code control systems may provide support for tracking versions of individual files, allowing a user to restore a file to any tracked version. A new version of a file may be created upon user request, and the version assigned a name. Some such systems also allow creating a named snapshot of a group of related files so that each file in the group of files can be rolled back to the named snapshot version. However, in order to roll back to a snapshot version, a user requests to create a snapshot in advance of needing to use it, and a user might not know a priori to which state they will want to roll back.
Backup systems store files, usually at a periodic interval or upon request, such that the system can use the stored files to revert the entire system state to what it was at the time when a backup was performed. The files backed up may include all files in the system, and these files might not be related to each other. Attempts have been made to support visually determining which backup should be used to restore the entire system, or from which backup a particular file or group of files should be restored. Apple's Time Machine Backup system provides a user interface that allows viewing folders as if flying through a time machine. The appearance of the folder at any time point provides clues regarding which backup contains which files. However, although this approach helps a user to identify the needed version of a particular file, it does not provide support for understanding the relationship among mutually dependent files wherever they may exist in a file system or distributed file system.
What is needed is an easy-to-use, intuitive way to look at a group of related files to determine at what snapshot in time the set of related files should be restored without having to rely on users creating and naming consistent snapshots a priori.